VolatileReadData - #203
Merged
Merged
Conversation
...because we will need the LazyReadData name for the ReadData that wraps LazyRead.
VolatileReadData is Closable. LazyRead is now also Closable. The VolatileReadData implementation LazyReadData closes its delegate LazyRead when it is closed. The file-system FileLazyRead locks the path it refers to on construction and holds the lock until it is closed (via a wrapping LazyReadData). All usages of KVA.createReadData have been revised to use try-with-resources to make sure VolatileReadData are properly closed. DefaultDatasetAccess has been revised to not eagerly materialize ReadData. This is in preparation of using partial loading and prefetching. (This is a separate topic, not necessary for using VolatileReadData correctly, but was too difficult to disentangle in the git history after the fact...)
* add a few tests
* test a list of nulls is returned for non-existing blocks * test number of backend read calls for readBlocks
Contributor
|
We should address this before merging (#204 ) |
…stem mount circumstances can lead to files being read/writeable, but not lockable. In these cases we should attempt to read, without locking, and immediately materialize as a best-effort attempt at ensuring valid data Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
…ead/write operations Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
…, so we handle it as `null` in PositionValueAccess Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
…ReadData` and `write` Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
… regex Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
…Access. In practice, it was not consistently used. Most `Paths` and `Files` static methods internally get a file system from the FileSystemProvider Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
This was referenced Feb 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
ReadDatareturned byKeyValueAccess.createReadDataare nowClosableVolatileReadData.For
FileSystemKeyValueAccess, theVolatileReadDataholds a (read) lock onto its underlyingFileChanneluntil it is closed. All usages ofKeyValueAccess.createReadDatahave been revised to use try-with-resources to make sure allVolatileReadDataare properly closed after use.The
LazyReadinterface has moved to its own file and is now also responsible for implementing theReadData.prefetchfunctionality (optional, currently does nothing).The
ReadDataimplementation that wrapsLazyReadis now namedLazyReadData(instead ofKeyValueAccessReadData) and was moved to thereaddatapackage.There was a previous
LazyReadDataclass that is now calledLazyGeneratedReadData(and it is fed by aReadData.Generatorinstead of aReadData.OutputStreamWritert).The new
LazyReadDataimplementsVolatileReadDataand forwardsclose()to its delegateLazyReadIn
DefaultDatasetAccess, we avoid preemptively materializingReadDatato check whether a given key exists. Instead, we work with theVolatileReadDataand appropriately handleN5NoSuchKeyExceptionwhen this is (later) thrown when working withLazyReadDatafor non-existing keys.We also make sure to materialize
modifiedReadDataeverywhere if write-locks would overlap withexistingReadDatalocks.